1. Field of the Invention
This invention generally relates to the field of object-oriented programming and class hierarchies and more specifically to constructing software systems by composing the code associated with a set of class hierarchies into an executable system.
2. Description of Related Art
Class hierarchy composition aims at constructing software systems by composing the code associated with a set of class hierarchies into an executable system, or by weaving separately written aspects into a class hierarchy. See generally William Harrison and Harold Ossher, “Subject-Oriented Programming (A Critique Of Pure Objects)” In Proceedings of the Conference on Object-Oriented Programming Systems, Languages, and Applications, pages 411–428, 1993 and Gregor Kiczales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jeffrey Palm, and William G. Griswold. An overview of AspectJ, In Proc. 15th European Conf. on Object-Oriented Programming (ECOOP'01), Budapest, Hungary, June 2001. Advocates of composition argue that, by putting the functionality associated with each system feature in a separate hierarchy, a better separation of concerns is achieved, resulting in code that is easier to understand, maintain, and change.
Although considerable amounts of work have been devoted to developing specification formalisms for software composition, and on the methodological aspects of compositional software development, current techniques and tools for hierarchy composition operate on a purely syntactical basis and cannot provide any semantic guarantees about the behavior of the composed hierarchy. It is thus our aim to develop a semantically well-founded notion of composition that enables reasoning about the behavior of composed class hierarchies. Accordingly a need exists to overcome the shortcomings of the prior art systems and to provide a semantically well-founded notion of composition that enables reasoning about the behavior of composed class hierarchies.
Research on aspect-oriented software development has been gaining in popularity recently see for example Communications of the ACM. 44(10), October 2001, “Special Issue On Aspect-Oriented Programming.” In essence, the goal of this field is to obtain more extensible and reusable designs by distributing unrelated functionality over disjoint hierarchies or aspects. To achieve this, a mechanism for composing these functionalities into executable code is needed. In our setting, this is accomplished by composing hierarchies. Aspect-oriented languages such as AspectJ (see Gregor Kiczales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jeffrey Palm, and William G. Griswold, “An overview of AspectJ”, In Proc. 15th European Conf. on Object-Oriented Programming (ECOOP'01), Budapest, Hungary, June 2001) have language constructs that allow one to specify the conditions under which a piece of advice is “woven in” at a joint point. Until recently, there has been very little work on the semanticfoundations of composition
The work most closely related to ours is the Aspect Sandbox (ASB) project by Wand et al. (see Mitchell Wand, Gregor Kiczales, and Christopher Dutchyn, “A Semantics For Advice And Dynamic Join Points In Aspect-Oriented Programming”, October 2001), who incorporate several key aspect-oriented language constructs such as join points, pointcut designators, and advice into a simple language with procedures, classes, and objects. Wand et al. formalize the semantics of this language using a denotational semantices. Wand et al. do not provide any guarantees about the noninterference of aspects, nor do they determine the semantic impact of “weaving in” an aspect.
Ernst presented a class hierarchy composition system, where the composition operator is built into the syntax of the programming language gbeta. Explicitly specified compositions may trigger propagation of implicit compositions, for example an explicit combination of methods or classes may trigger implicit composition of other (e.g. auxiliary) methods or classes. Ernst showed that his composition system and propagation mechanism preserve static type correctness, but nothing is said about preservation of dynamic client behavior.
Our approach is similar in spirit to the work by Binkley et al. (see David Binkley, Susan Horwitz, and Thomas Reps “Program Integration For Languages With Procedure Calls”, ACM Transactions on Software Engineering and Methodology, pages 3–35, January 1995.) on the integration of C programs that are variations of a common base, by analyzing and merging their program dependence graphs. Similar to our work, Binkley et al. use an interference test, which is a sufficient criterion for noninterference. The main differences between Binkley et al. and our work is that Binkley et al. operates at the statement level, whereas our techniques operate on calling relationships between methods. Binkley et al. do not consider object-oriented language features.
Composition of object-oriented programs has been studied by other authors in the context of component-based systems. See Oscar Nierstrasz and Dennis Tsichritzis (ed.). “Object-Oriented Software Composition”, Prentice Hall, 1995. One approach is concerned with the dynamic interaction of concurrent objects, and the goal is to create new behavior as a composition of given behavior. Our approach aims to preserve old behavior while combining given behavior. Another line of research has investigated the composition of systems from components, where the components are treated as black boxes and come with some interface specification, usually in the form of a type system.